Community Wisdom 180
👋 Привет! Добро пожаловать в очередной выпуск ✨ Community Wisdom ✨ — еженедельную рассылку только для подписчиков, которая выходит по субботам и собирает самые полезные обсуждения из нашего закрытого Slack-сообщества.
Спасибо спонсору этого месяца — Clerk. Clerk позволяет запустить продакшн-авторизацию моментально, не тратя инженерные спринты на логин/регистрацию. Все нужное для приложения: готовые компоненты, организации для B2B multi-tenancy, встроенный биллинг подписок и многое другое — плюс поддержка MCP-сервера, чтобы AI-агенты могли авторизовываться и действовать от имени твоих пользователей. Строй продукт, а не слой авторизации. Подробнее здесь.
Нажми на название города, чтобы узнать подробности и зарегистрироваться:
Не нашел свой город и хочешь организовать митап? Напиши @Riya в Slack. Подробнее здесь.
От скептика к искреннему верующему: как OpenClaw изменил мою жизнь | Claire Vo: YouTube, Spotify, Apple Podcasts
Как в Stripe создали «миньонов» — AI-агентов для кодинга, которые отправляют 1 300 PR в неделю + Как превратить Claude Code в операционную систему личной жизни: YouTube, Spotify, Apple Podcasts
У меня срочный вопрос — сегодня созвон с COO небольшого стартапа (27 сотрудников), который предоставляет данные как услугу нефтегазовым компаниям. У меня на руках оффер, и давно не было ситуации, когда в пакет входят акции/опционы. Я попросил его созвониться и рассказать подробнее про долю. Всё, что мне известно: я получаю X опционов согласно их плану стимулирования акционерным участием (документ, к которому у меня нет доступа). Я собираюсь запросить сам план, общее количество акций, цену страйка. Это нормально и разумно? Любые подсказки будут полезны. ↗—Kira Barrett
Jon Roemer: Абсолютно разумно. Доля — часть совокупной компенсации, так что тебе нужна вся информация, чтобы принять осознанное решение до подписания.
Peter: Как и сказал Jon, это нормально. В зависимости от уровня позиции и твоего веса в переговорах можно попросить пообщаться с инвестором. То, что люди готовы (или не готовы) рассказывать, говорит о многом. Я напоминаю себе, что доля — это лотерейный билет. Следующие раунды размывают твою долю, а инвесторы с привилегированными акциями получают деньги раньше тебя при ликвидации. Ожидаемая стоимость твоей доли — низкая... если только ты не приходишь в компанию, которая уже растёт бешеными темпами, удваивая или утраивая выручку. Если нет — убедись, что базовая зарплата покрывает твои потребности, даже если акции в итоге не будут стоить ничего.
Kira Barrett: Спасибо, полезно! Дополнительный контекст: они не привлекали внешнее финансирование и устно обязались перед командой никогда не брать деньги извне. Медленно и стабильно. Однако они планируют подготовиться к поглощению в ближайшие ~7 лет. Выручку точно не удваивают и не утраивают. У меня нет права голоса и я не в руководстве. Что касается размытия доли при найме — думаю, к моменту поглощения они вырастут максимум до 100 человек, но опять же, всё спекулятивно! Спасибо за подсказки.
Jon Roemer: Ну да, конечно, каждый стартап во вселенной якобы к этому идёт. Пока нет реальной суммы в долларах, которую можно превратить в наличные, доля — это фантики. Опционы не настоящие, пока не станут настоящими.
Gautam Banerjee: Могу скинуть свой калькулятор опционов, который я получил вместе с оффером, если хочешь. Просто напиши в личку. Он помогает оценить стоимость опционов при разных сценариях.
Ashwin: Вообще-то очень необычно, когда маленький стартап не даёт доступ к документам плана стимулирования, чтобы ты мог показать их юристу. Тебе обязательно нужно узнать цену страйка, последнюю оценку 409A, общее количество акций, ликвидационные преференции и pari passu ли они.
Joshua Herzig-Marx: Надеюсь, разговор пройдёт хорошо! Смысл в том, чтобы оценить стоимость твоего пакета опционов по формуле: кол-во опционов × (текущая стоимость акции − цена страйка). Моё правило: если вестинг стандартный, 4 года, то годовой объём должен быть не меньше 50% от базовой зарплаты. (Для руководящих ролей я жду 2% на seed-стадии и 1% на серии A.) Если нужны сравнения — смотри withautograph.com.
Всем привет, тут очень фрустрированный фаундер. Пытаюсь поднять pre-seed и вижу, что фонды говорят: «мы инвестируем до продукта», а когда слышат, что продукт уже запущен, начинают копаться в данных и путают сигнал с тракшеном. Есть советы? Как выйти на правильных инвесторов? ↗—Thais Blumenthal
Jen Polson: Можешь подробнее рассказать, что значит «путают сигнал с тракшеном»? Как инвестор, я бы точно хотела видеть все данные, которые есть у компании, чтобы снизить риск, включая продуктовые данные, если они доступны.
Thais Blumenthal: У нас меньше 1 000 пользователей. Мы общались с инвестором, который сказал, что инвестирует до продукта, а раз наш продукт уже запущен — попросил показать данные. Справедливо! Мы в бете 3 месяца, ретеншн 60%, отличные кейсы использования. Есть хороший сигнал вовлечённости, но 3 месяца бета-продукта — это не то, что я бы назвала полноценным тракшеном. В итоге они ответили, что мы слишком ранние для них (хотя инвестируют до продукта) и что у нас сильная команда с отличным problem-founder fit (я ex-Waze, решаю задачу пешеходной навигации), но хотят увидеть больше тракшена. Попросили вернуться, когда будет 10 000 MAU. Всё справедливо, но запутанно — я сразу озвучила количество пользователей и спросила, инвестируют ли они на такой стадии. Они сказали «да», перешли к следующему этапу — а потом отказали. Суть в том, что критерии оценки рисков не озвучиваются заранее, и я не понимаю, как определить, действительно ли фонд инвестирует в pre-seed...
Kevin Porter: Привлечь венчур — это реально тяжело, если у тебя нет очевидного и сильного тракшена. Инвесторы ищут один из 50 поводов сказать «нет» — тебе и любому другому фаундеру. Так это устроено. То, что фонд готов послушать питч или что он инвестирует в твою нишу, не значит, что он вложит деньги. A16z недавно перепостил статью Ben Horowitz от 2007 года про суть венчура — рекомендую, она помогает понять, как думают инвесторы. Альтернативная стратегия — найти бизнес-ангелов вместо венчура, а к фондам вернуться, когда будет больше тракшена.
Jen Polson: Полностью согласна с Kevin. Похоже, что-то в твоих данных не совпало с их инвестиционной стратегией. По моему опыту, «вы слишком ранние» — это очень распространённый способ отказать, вне зависимости от раунда. Ещё для контекста про ангелов: мой последний ангельский раунд был в формате питч-соревнования, и там было много компаний с показателями, похожими на твои.
Jason McCoy: К слову, даже очень сильным фаундерам часто нужно получить 100+ отказов, чтобы услышать одно «да». И ещё — тракшен можно определить только через доказательство работающей бизнес-модели. Сколько человек платит, какова скорость привлечения платящих и ускоряется ли она? Рост пользователей или вовлечённости — это не доказательство движения к product-market fit. Раунд может занять 6–9 месяцев. Может, лучше за это время начать зарабатывать? Многие фаундеры привлекают венчур, чтобы платить себе зарплату и уйти в фултайм, но венчур лучше использовать как ускоритель роста для масштабирования GTM/выручки. Я знаю несколько фаундеров, которые подняли $2–4 млн, сожгли всё и так и не нашли рабочую бизнес-модель.
Thais Blumenthal: Спасибо всем! Очень дельные мысли. На самом деле мы уже подняли около $500K от ангелов и хотели привлечь одного фонд до того, как начнём тратить, но сейчас переосмысливаю подход. Да, мы B2C и сейчас прорабатываем B2B-направление, чтобы продлить ранвей.
Thomas: Ищи тех, кто полностью убеждён и готов идти до конца. Остальное — шум :-)
Eric: Могу понять. Инвесторы бинарно смотрят на тракшен: лучше не иметь его вообще. Мало тракшена = нет product-market fit, а отсутствие тракшена — это асимметричная ставка. Хотя бы ангелы есть. Я сам всё ещё пытаюсь раскачать свой QCX. Для B2B нужен безупречный клиентский опыт.
Кто-нибудь строил граф знаний для своей организации? Было бы интересно узнать, как вы к этому подошли, что сработало, а что нет. Даже если была похожая идея, но вы её не реализовали — почему? Я хочу построить граф знаний для продукта: как он работает, какие решения принимались, как менялись версии, почему, что не получилось, и т.д. Для организации: кто есть кто, чем каждый занимается, над чем работал, как устроены процессы. Всё это — для новых сотрудников и для AI-агентов, которых мы будем строить. Контекст: я недавно присоединился к новой организации. Мы небольшая команда (30–40 человек), строим SaaS в отрасли, которая мало использовала технологии. Мы хотим быть AI-native организацией, но, будучи маленькой командой, сфокусированной на поставке фич, мы запустили документацию. Я понял, что хорошая документация даёт кумулятивный эффект — особенно если хочешь стать AI-native. Как новый член команды, считаю это приоритетом и чем-то, в чём могу помочь. ↗—Mahendra B
Wouter: Хороший вопрос, у меня та же проблема.
Loren Rogers: Я на самом деле построил для себя нечто очень близкое к тому, что ты описываешь, и могу поделиться, что сработало. Я использую Obsidian как граф знаний, а Claude Code — как движок для наполнения. Начал с того, что просто попросил CC написать файл CLAUDE.md для себя в директории Obsidian Vault. Я подробно описал, какие вещи важно фиксировать, но не указывал, как структурировать данные. Дальше — просто загружал как можно больше информации. Шаблонов нет — каждая тема принимает ту форму, которая ей подходит. CC расставляет вики-ссылки при записи, и граф строится органически по мере накопления информации. Почему это работает как «AI-native» база знаний: Claude может рассуждать по всему хранилищу. У него есть контекст — что существует, что с чем связано, что менялось недавно. У меня есть кастомные скиллы для быстрого захвата (вываливаешь всё из головы, и оно само раскидывается по нужным страницам), ежедневных брифингов (подтягивает из хранилища + календаря + интеграций) и сессий ведения дневника, которые обновляют страницы знаний как побочный эффект разговора. Я отношусь к этому как к бесконечной памяти для CC, и иногда обращаюсь к .md-файлам напрямую через Obsidian, но в основном работаю через CC. Поначалу всё довольно хаотично, но структура сама проявляется со временем. Главный инсайт: пусть AI пишет в базу знаний как часть обычных рабочих процессов, а не как отдельная задача «надо задокументировать». Именно это решило проблему заброшенной документации. А потом можно оформить всё как Git-репозиторий и расшарить с командой — пусть вносят знания через PR.
Aaron Nichols: Поддерживаю многое из того, что описал Loren. Мы начинали так же, и для одного человека это работает неплохо. Потом перешли на общее хранилище Obsidian — пользуемся им сейчас. Но для мультиплеерных сценариев, когда нужен доступ для многих и информация должна оставаться актуальной, нам пришлось строить кое-что другое. Есть и технические, и организационные трудности. На рынке есть инструменты для сбора информации из разных источников, но мало кто позволяет категоризировать данные так, чтобы поиск был надёжным на больших объёмах. Нужно курировать контент, который считается доверенным и «золотым», и отделять его от остального шума. Для базы знаний это более-менее прямолинейно. Мы сейчас работаем над тем, чтобы эта информация помогала принимать решения и анализировать прошлые — и вот тут становится сложнее, хотя появляются интересные проекты в этой области.
Pedro Brandão: Всё становится очень сложным, как только систему начинает использовать больше людей. Меня удивило, как быстро всё превращается в шум, если не разделять «доверенное» и просто «зафиксированное». Видел настройки, которые выглядят отлично поначалу, а через пару недель никто не понимает, чему верить. Помогло привязать базу знаний к реальным рабочим процессам, а не делать отдельный слой. Иначе это становится очередной штукой, которую перестают обновлять.
Aaron Nichols: На практике я видел, что это работает, когда знания — не то, что люди «пишут», а то, что система генерирует как побочный продукт рабочих процессов. Например, каждый раз, когда запускается процесс (классификация, экстракция и т.д.), ты логируешь: ввод, модель/версию, результат и то, был ли он принят или скорректирован (HITL). Со временем это и становится твоим реальным слоем знаний — не то, что люди задокументировали, а то, что система выучила и верифицировала. Иначе всё быстро расходится с реальностью...
Sandhya Simhan: Не начинай с попытки «построить граф знаний» как отдельную штуку. Начни со строительства живого слоя из:
А потом вывести граф из этого. Вот что, по моим наблюдениям, работает:
Что, по моим наблюдениям, не работает:
Если бы я делал это для небольшой, быстро двигающейся команды, я бы подал задачу не как «мы строим граф знаний», а как «мы создаём живую память продукта и организации для онбординга и AI-агентов». Это обычно ведёт к лучшему внедрению, и в итоге приходишь примерно туда же.
Просто интересно (не срочно): может кто-нибудь объяснить простым языком, почему некоторые так категорически против MCP? Спасибо! ↗—Glasha Marcon
Roberto Mendoza: Жрут токены, то есть просто неэффективны для части задач по сравнению с обычным API или CLI.
Este Lopez: Они часто раздувают контекстное окно AI (его краткосрочную память), что приводит к замедлению, путанице и ошибкам. Зависит от задачи — переключайся на API для кастомных агентов, скриптов или чего-то, где важна надёжность. Используй MCP только для личных задач без кода, где «просто работает» — главный приоритет.
Ilya Subkhankulov: Разве эти проблемы не зависят от реализации? Если MCP-сервер прожорлив на токены — это претензия не к протоколу как таковому. API или CLI могут страдать тем же или хуже.
Aaron Nichols: Есть разница между потреблением токенов до использования и во время. Да, некоторые жрут много в любом случае, но MCP расходует токены уже просто тем, что загружен — вот на что люди обычно указывают. У меня есть ещё один аргумент против MCP — совместимость с несколькими агентами. Если я использую MCP, мне нужно настроить его в каждом агенте, а у меня их несколько. Если я использую CLI — авторизуюсь один раз на машине, и всё, все агенты могут им пользоваться. Если объединить CLI со скиллом, который заранее объясняет, как работать с CLI, — это, на мой взгляд, гораздо эффективнее, чем ограниченный контекст в MCP, потому что MCP стараются экономить токены в неактивном состоянии. Эта же причина, почему мне сильно не нравится Claude Cowork — он не может использовать эти инструменты. По сути, меня вынуждают использовать их коннекторы — отлично, если тебе подходит, мне — нет.
Ilya Subkhankulov: Логично, список инструментов раздувается. Ты заменяешь обнаружение инструментов скиллом.
Miroslav Pavelek: В Cowork тебя не заставляют использовать их коннекторы — можно написать скилл для доступа к инструментам через API.
Aaron Nichols: Да, через API, но не через CLI. Во многих случаях — возьмём CLI gog для примера — нет уж, спасибо решать это через API/скиллы. И ещё мне не нравится, когда агент берёт на себя авторизацию. Чтобы было понятно — если ты направляешь агента на API и просишь его написать скилл для взаимодействия, а API требует авторизации, то агенту приходится формировать запросы с твоими учётными данными. Будь то токен или API-ключ — всё это передаётся провайдеру инференса в открытом виде и навсегда сохраняется в их системах наблюдения. Можно заставить агента написать обёртку, которая считывает токен и настраивает всё самостоятельно, но это нужно делать осознанно. Когда авторизацию берёт на себя CLI, агенту гораздо сложнее получить доступ к учётным данным, и они не проходят через инференс. В случае MCP-сервера для этого есть специальный OAuth-поток, и сервер обрабатывает авторизацию в коде, не передавая её агенту.
Marcel Fiala: Добавлю, что раздутие токенов — не единственная проблема эффективности MCP. Инструменты не композируемы (нет простого способа передать результат одного инструмента другому напрямую), а значит тратятся лишние ходы агента (и перепроигрывание всей сессии, закешированной или нет). Anthropic работает над решениями (например, PTC), но по моему опыту модели пока не очень эффективно это используют. Плюс всегда теряется часть наблюдаемости.
Aaron Nichols: Отличное замечание — впечатляет, как агенты цепочками выполняют команды, и ничего из этого недоступно через MCP. Это не только тратит ходы агента, но и снижает детерминированность, когда агенту приходится манипулировать данными вместо инструмента. Наверное, это многое объясняет — почему CLI-инструменты ощущаются эффективнее (и быстрее).
Marcel Fiala: Ага, для последнего (и самого сложного) агента я пошёл по пути кастомного JSON-AST (агенту доступен только один инструмент execute_script) вместо MCP с 30 инструментами. Экономия токенов (сокращение контекста + сокращение числа ходов) — на порядок.
Aaron Nichols: Аналогично — у меня был инструмент, который хотел показать 100+ тулов через MCP. Я использую один CLI и один скилл.
Sani: Удивлён, что никто не упомянул... MCP постоянно отваливаются. Это жутко бесит.
Хотела узнать, что вы думаете о новости, что Monzo уходит из США. Стратегические решения Monzo понятны, но лично мне обидно. Мне нравился Monzo, а меньше конкуренции обычно ведёт к ухудшению качества продуктов. AI пересказал мне Reddit как: «...реакция на уход Monzo из США — смесь глубокой фрустрации лояльных пользователей... Настроение: «усталость от финтеха»... Для многих это очередное «разбивающее сердце» закрытие цифрового банка.» Интересно услышать мнения. ↗—Iuliia Nemudrova
Max: Мне всегда нравилась идея цифровых банков вроде Revolut или Monzo, но как только смотришь на предложения, всегда ощущение промежуточной ценности на рынке.
Хотелось бы загореться необанками. Может, я просто оптимизатор, но каждый раз выбирал лучший инструмент для каждой задачи, а не одного провайдера на всё.
Miroslav Pavelek: Как европеец, мои пять копеек (чисто личное):
Iuliia Nemudrova: Спасибо за мысли. На 100% согласна с утверждением, что рынок США сильно фрагментирован — с очень низкой централизацией даже на уровне инфраструктуры (например, нет единого стандарта P2P-платежей), что мешает пользователям сосредоточиться на одном основном провайдере. Хотелось бы видеть рынок, где и традиционные, и необанки имеют примерно одинаковые базовые предложения, но конкурируют по UX или дополнительным фичам — например, расширяются в «финансовый лайфстайл» и становятся больше партнёром, подстраиваясь под ментальные модели людей, а не регуляции... что необанки, в принципе, умеют хорошо, но проваливаются в «базовой» части. И пока необанки буксуют с ростом, реальной дизрупции для индустрии не будет, и традиционные банки продолжат выпускать посредственные цифровые продукты. Так что лично мне эта новость расстроила.
Max: Да, лучший UX и ментальные модели, но с посредственными финансовыми продуктами — для меня это всё равно промах.
Продуктивной и наполненной недели 🙏
Если кому-то из твоих знакомых была бы полезна эта рассылка или сообщество, можешь подарить подписку 💞 Есть групповые скидки, подарочные варианты и бонусы за рефералов.
С уважением,
Kiyani 👋